This application claims the priority of German patent document 100 08 973.9, filed 25, Feb. 2000, the disclosure of which is expressly incorporated by reference herein.
The invention relates to a process for ensuring the data integrity of software for a control unit of a motor vehicle.
Current increased utilization of electronics and of communication systems in vehicles has generated a growing demand for measures to assure data and software security.
For example, microcontrollers, which are now used for control purposes in many different areas of the vehicle, are often connected by one or more bus systems. In most cases, it is possible (for example, via a diagnostic connection) to access this bus from outside the vehicle, and to communicate with the individual control units.
The operation of the control units (sometimes referred to simply as a “controller”) is controlled by software programs, which have usually been filed heretofore in a non-programmable memory (for example, in the case of masked microcontrollers). As a result, the software cannot easily be manipulated. For example, the complete exchange of a memory chip for another memory chip can be detected and remedied. However, the future use of programmable, particularly so-called flash-programmable control units in the vehicle increases the risk of unauthorized manipulation of the software, and of the operation of the control units; the exchange of software by unauthorized persons could simply take place at low expenditures by reprogramming.
However, for security reasons, and to meet legal requirements, measures must be taken which either prevent a changing of original software, or which allow only authorized persons to make such changes.
In addition, it may be advantageous in the future to follow a uniform-parts concept, in which the same hardware is used in different models. Operational differences will then be achieved merely by different software. (This concept, of course, requires that certain software can be run only in an individual vehicle and cannot easily be copied.)
A large number of authentication processes and systems are known from the prior art. For example, U.S. Pat. No. 5,844,986 discloses a process for avoiding unauthorized intervention in a BIOS system of a PC. Based on a so-called public-key process with public and secret keys, a cryptographic coprocessor, which contains a BIOS memory, carries out, an authentication and examination of a BIOS change by checking a digital signature embedded in software which is to be imported into the system. Moreover, European Patent Document EP 0 816 970 discloses a system for examining corporate software in which a system for authentication of a boot PROM memory comprises a memory part with a microcode. An authentication sector comprises a hash generator which generates hash data in response to the implementation of the microcode. Neither of the above-mentioned processes or systems, however, permits direct examination of software to be imported into a control unit of a motor vehicle.
European Patent Document EP 0 813 132 discloses an authentication process in which a program is coupled with a certificate and an access list. According to a preferred embodiment, a certifying agency generates one certificate for a code and one certificate for the access list. Once the certificate has been allocated, it will no longer be possible to change the code or the access list without violating the certificate. The code and the access list are stored together with their certificates in a server. By means of this process, a customer, who requests the code or the access list, can determine their authenticity. However, it is not easy to apply this process to the motor vehicle field.
It would generally be advantageous to utilize several authorized parties for generating and authentically characterizing requested software. As a result, such characterization would not have to be carried out by a central location alone. However, in addition, a central monitoring point should also be set up for issuing the authorization to selected authorized parties.
It is an object of the present invention to provide a process for ensuring the data integrity of software for a control unit of a motor vehicle, in which several authorized parties which can be controlled by a central system, can generate authentic software and correspondingly characterize it.
This and other objects and advantages are achieved by the process according to the invention, in which a central system (referred to herein as a trust center), can issue one or more certificates to authorized parties, which enable them to properly sign software for a control unit and import it into a vehicle so that it is capable of running. For this purpose, for example, the trust center (in an alternative embodiment, the vehicle itself) provides a pair of control unit keys having a first and a second key. The first key is stored, during the production of the vehicle, in the control unit itself or where it is accessible to the control unit. By means of the second key of the trust center, a first certificate for an authorized party, in the following called the certificate holder, is signed.
For reasons of clarity, it will first be assumed that only one certificate is required for an executable reading of new software into a control unit. In a certification information part, this certificate contains, in addition to specific certificate information, at least a first key of the certificate holder who has himself generated a pair of certificate keys with a first and a second key. For example, the certificate issuer, a serial number, the certificate holder, certain access rights or a validity period can be defined as additional certification information.
The authorized party or certificate holder will then sign the software to be imported into the control unit, by means of his second key of the pair of certificate keys. Both the certificate and the software signed by the certificate holder will then be imported into the control unit of a vehicle. By means of its own first key of the pair of control unit keys, the control unit recognizes the legality of the certificate and accepts the certificate information, including the key contained therein. By means of this key (the first key of the pair of certificate keys), the signature of the imported software is checked. If this signature is also recognized as unobjectionable, it will be accepted by the control unit.
By means of this approach, changing and signing rights can generally be awarded. Not all software has to be signed by the holder of the pair of control unit keys, for example, the trust center itself. By means of the additional information in the certificate, it is also possible to assign to the certificate holder a large number of concessions or restrictions. For example, a time period can be granted for which the certificate holder can generate and import software. Various authorization levels for generating software and the type of software can be awarded. However, the signing of the software itself always takes place by the certificate holder himself.
Keys are generally coding and/or decoding parameters which can be used in known cryptographic algorithms. Moreover, both symmetrical and asymmetrical processes can be used: in symmetrical processes, the two keys are identical so that actually only one key need be present at different sites, while in an asymmetrical process, different keys are used. One generally known asymmetrical process is the public-key process, in which a public and a secret (private) key are generated. The public key may be known to anyone. Such cryptographic algorithms are, for example, the Rivest-Shamir-Adleman (“RSA”) Algorithm, Data Encryption Algorithm (DEA Algorithm) and similar algorithms, which are asymmetrical processes. These algorithms can be used for both the first and second pairs of keys.
In a more complex further development of the present process according to the invention, not one but several certificates n are awarded for checking software imported into a control unit. This results in further design possibilities. On the one hand, it is possible to distribute various certificates to different persons, so that an executable importation of new software into a control unit can be implemented only jointly. In addition, it is possible to award various access rights by way of the different number of certificates.
When several certificates are used, the signature of the first certificate can be checked by means of the key filed in the control unit. The signature of each additional certificate can, in turn, be checked by means of the key contained in a previously accepted certificate. By means of the key in the last certificate, the signature of the software itself is finally checked. Only if all checks have been successful, will the software be accepted by the control unit. In order for the signature of a certificate to be checked by means of the key contained in a previous certificate, it must have been signed by means of the second pertaining key.
The selection as to where the secret keys and the public keys are in each case to be filed can be varied greatly. For example, the public keys are, in each case, filed in the certificate information of a certificate. The public key of the pair of control unit keys can also be filed in the control unit. Correspondingly, the signature to be checked must have been formed by means of the pertaining secret key.
Naturally, other embodiments are also possible in which the secret keys are filed in the certificate information and/or in the control unit itself. Combinations with symmetrical keys are also possible.
The key filed in the control unit is best filed in the boot sector, which is normally protected in a special manner. To increase security, the boot sector can also be constructed such that, after the inscription and the filing of the key contained therein, it is “blocked” (that is, blocked for future access, particularly writing access).
If all checks are positive (certificate check and software check), the software is accepted by the control unit or a system provided specifically for this purpose and can be used for controlling of the control unit.
As described above, the public key in the case of the so-called public-key process may be publicly known, whereas the secret key is known only at an authorized party.
According to a special embodiment, the secret key of the pair of control unit keys is known only to the trust center and the secret key of a pair of certificate keys is known only to the certificate holder. By means of each secret key—analogous to a handwritten signature—a digital signature can be generated for an electronic document (certificate, software). Only the holder of the secret key can generate a valid signature. The authenticity of the document (certificate, software) can be checked by the verification of the signature by means of the public key. An unauthorized third party, who does not know the secret key, will not be able to generate a valid signature. If a manipulated, expired or non-authorizing certificate is loaded into a control unit, or manipulated and not correctly signed software is loaded into the control unit, this is recognized by means of the respective pertaining key and the control unit is changed to a inoperable condition.
When a symmetrical process is used, to increase security, an additional activating protection can be used in the form of special hardware.
In order to meet the demands attending use of the software exclusively for an individual vehicle, the software provided for a control unit of a specific vehicle contains vehicle-specific information, such as the chassis number or other vehicle-specific data. This information is assigned to the software or integrated in it. Only after the assignment or integration of these data to or in the software, will this software then be signed by means of the second key of the certificate holder of the last certificate. As described above, a control unit will accept the software only if, on the one hand, the certificate or certificates and, in addition, the signature of the software were recognized as being unobjectionable. Because the signature depends on the vehicle-specific information contained in the software, it cannot be subsequently changed. Software can be fed so that it can be run by a control unit of a vehicle only if the vehicle-specific information is not changed and actually corresponds to that of the vehicle. Copying of such individualized software to another vehicle is therefore impossible.
In order to provide another security level during the importing of software into the memories of the control unit, it should be possible to access the memory of the control unit beforehand only by means of a corresponding authorization. For this purpose, before the signed software is exported, the control unit is “unlocked” in a log-on step. When different prioritized levels are used during the log-on, in addition, differently designed access rights may be awarded. For example, in the case of a diagnostic access, a log-on would first be required, whereby the control unit recognizes by means of the fed access information the access rights and the authorization step connected therewith. Depending on the awarding of rights, the access authorizations may be classified from uncritical to very critical. The awarding of the rights can be designed to be static so that, for example, different access codes are issued for certain authorization stages. As an alternative, the awarding of rights can be designed to be dynamic so that, for example, access certificates are awarded in whose certificate information contains the authorization stage.
In one embodiment, the checks of the signatures are carried out in the control unit itself. According to another embodiment, at least one check can be implemented in an own access control. Because of the centralization of the security function with respect to the award of access rights, a control unit which may be provided exclusively for the access control, in comparison to the other control units should not be accessible in the motor vehicle because the above-described protection mechanisms could possibly be circumvented by physical removal of a control unit.
In order to prevent a control unit from being completely removed and replaced by another, an additional control unit removal protection may be useful. For this purpose, for example, a control unit authenticity check is carried a periodically out in a vehicle, in which the control units are integrated. An inquiry is therefore occasionally directed to each control unit, and the latter must answer with specific expected information. If the information actually emitted by the control unit to be tested does not correspond to the expected information, or if the control unit does not answer, suitable safety measures will be taken. For example, the control unit is excluded from the communication composite, or the control unit is registered, characterized or entered into a list. During a diagnosis of the vehicle, the manipulation can then be detected. In the above-described embodiment, the control units respond upon request, for example, by means of a secret, control-unit-specific authentication key. An illegally exchanged control unit does not have such a key and will therefore not be accepted.
Other objects, advantages and novel features of the present invention will become apparent from the following detailed description of the invention when considered in conjunction with the accompanying drawings.